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SOflMARY 


Problen 

k  software  system  is  required  which  will  allow  the  experimental 
investigation  of  embedded  operator  performance  evaluation 
techniques  in  data  transaction  systems.  To  permit  meaningful 
research,  the  system  must  provide  the  experimenter  a  wide  latitude 
in  the  design  and  generation  of  a  data  transaction  task. 

Approach 

A  generic  data  transaction  system  was  appraised  to  be  a 
suitable  vehicle  for  attaining  the  above  stated  goals.  Such  a 
system  would  consist  of  a  functionally  complete  set  of  primitive 
operators  which  could  be  used  to  process  a  random  access  dataset. 
Through  the  use  of  a  hierarchically  organized  description,  a 
programmer  would  communicate  to  the  genetic  system  the  definition 


of  a  specific  application. 

i. e-,  record  and  display 

formats. 

The 

additional 

provision 

for 

user  supplied  software 

appendages 

at 

strategic 

points  in 

the 

generic  system  imparts 

syn tactic 

and 

semantic  extensibility  to  the  native  minimal  query  language. 
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Besults 


&  generic  data  transaction  systee  was  impleaented  in  FORTRAN  IV 
and  Assenbly  language  on  a  oinicoaputer  with  28K  words  of  nenory, 
a  cartridge  disk  subsysten,  a  prograonable  real  time  clock,  and  a 
plasma  panel  terminal  (Including  512  by  512  pixel  ac  plasma  panel, 
32  by  32  resolution  touch  sensitive  panel,  and  ASCII  or  PLATO 
keyset) .  The  flexibility  and  extensibility  Of  the  generic  system 
were  found  to  be  acceptable  for  the  implementation  of  experimental 
(research  and  non-research)  applications. 

Conclusion 

A  table  driven  generic  data  transaction  system  consisting  of  a 
functionally  complete  set  of  primitive  operators  and  an  extensible 
minimal  query  language  is  a  desirable  vehicle  for  allowing 
experimental  investigation  into  many  aspects  of  the  design  and 
utilization  of  data  transaction  systems.  Additionally,  due  to  the 
relative  ease  with  which  an  application  nay  be  created  or 
modified,  the  generic  system  has  merit  in  a  non-research 
environment  as  well. 

Recommendation 

The  generic  system  approach  which  was  applied  to  event-based 
systems  in  this  investigation  should  also  be  applied  to  time-based 
systems  with  the  expectation  of  similar  encouraging  results. 


DISCLAIMER 


The  software  systen  described  in  this  docunent  is  the  product 
of  the  authors  alone  and  does  not  incorporate  any  suggestions  from 
any  other  individuals  or  uncited  sources.  The  authors  make  no 
guarantee  of  the  accuracy  of  any  part  of  this  docuoent  or  the 
software  system  and  assume  no  responsibility  or  liability  for  any 
consequences  of  its  usage  under  any  conditions.  Duplication  of 
the  documentation  or  software  whether  in  part  or  in  full  by 
whatever  means  and  for  whatever  purpose  is  permitted  only  with  the 
inclusion  of  proper  reference  to  authorship. 
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I.  INTBODDCTION 

In  order  to  alloM  the  experimental  investigation  of  embedded 
operator  performance  evaluation  techniques  in  data  transaction 
systems,  a  generic  data  transaction  system  was  developed  with 
which  many  different  transaction  systems  could  be  implemented  and 
studied.  The  subject  interface  to  the  generic  system  consists 
essentially  of  a  512  by  512  pixel  ac  plasma  panel  output  device  on 
which  formatted  alphanumeric  and  graphical  information  may  be 
displayed,  and  a  (ASCII  or  PLATO)  keyboard  and  32  by  32  resolution 
touch  sensitive  panel  through  which  the  subject  may  interact  with 
the  system. 

To  provide  the  flexibility  necessary  for  the  implementation  by 
the  experimenter  of  both  novel  and  conventional  but  dissimilar 
data  transaction  systems,  it  was  necessary  that  a  table  driven 
scheme  be  used  in  the  design  of  the  generic  system.  Through  the 
use  of  the  available  tables  (or  descriptors)  explained  in  this 
document,  the  experimenter  is  allowed  a  wide  latitude  in  the 
design  and  generation  of  a  data  transaction  tisk  for  use  in  his 
research.  Also,  the  generic  system  provides  a  functionally 
complete  set  of  primitive  operations  from  which  complex  query 
languages  may  be  constructed  by  the  experimenter.  Alternatively, 
if  the  experimenter  desires,  the  primitive  command  language  can  be 
used  directly  as  provided.  The  information  base  for  the  generic 
system  consists  of  nonhomogeneous  hierarchically  organized  (file. 
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record,  page,  field)  binary  coded  data  stored  on  direct  access 
online  mass  storage. 


The  entire  generic  system  was  implemented  on  a  PDP  11/55  mini¬ 
computer  with  28K  words  of  core  memory,  an  HK05  disk  drive  with 
RKlI  controller,  a  KW11-P  real  time  clock,  all  manufactured  by 
Digital  Equipment  Corp. ,  and  a  GCC-IB  plasma  panel  terminal 
manufactured  by  Information  Technology  Ltd. 

This  technical  report  is  the  first  of  three  documents 
describing  the  Generic  Data  Transaction  System.  The  second, 
(HFL-79-3 /NPRDC-79-2) ,  contains  a  complete  set  of  source  listings 
for  the  system.  The  third,  <HFL-79-4/NPPDC-79-3) ,  contains  a 
user's  guide  and  sample  application-specific  user  routines. 


II,  CONTROL  CYCLE 


The  execution  of  the  generic  data  transaction  system  consists 
of  an  initialization  phase  during  which  files  are  opened,  control 
variables  are  initialized,  and  completion  routines  are  specified, 
followed  by  the  execution  phase  which  consists  of  a  single  loop 
within  which  either  a  command  is  interpreted  and  executed  or  a 
field  update  is  applied.  Asynchronously,  the  touch  panel  may  be 
used  in  the  specification  of  a  field  for  updating.  The  optional 
user  timing  of  character  writing  delays  as  a  synchronous  extension 
of  the  plasma  panel  interrupt  handler  occurs  asynchronous  to  the 
rest  of  the  execution  phase  and  program  termination  occurs 
synchronously  in  response  to  a  <CTRL-C>  eguivalent  on  the 
keyboard.  The  following  outline  summarizes  the  (optional) 
operations. 


I.  Initialization 

A.  Open  files 

B.  Control  variable  assignments 

C.  Specify  completion  routines 
(D.  U  ser  supplied  initialization) 

II.  Execution 

A.  User-performance  recording 

B.  Input  prompting  (user  supplied  prompting) 


Command  input;  also,  translate  end-of-file  to 
<CTRL-Z>  command,  and  error  to  <CTRL-C>  command 
User-performance  recording 
Update  mode: 

1.  Preliminary  verification  or  update  request 
cancellation 

2.  {User  supplied  conversion  (and  field  updating) ) 

and/or  conversion  and  field  updating 

3.  Error  reporting  (user  supplied  messages)  and 
user-performance  recording 

or  command  mode: 

1.  (User  supplied  command  interpretation  (and 

execution))  and/or  command  interpretation,  and 
user-performance  recording 

2.  Command  execution  -  select  from: 

a,  LOGON  (user  supplied  messages) 

i.  Control  record  processing 

ii-  Device  activation 
(iii.  User  supplied  extensions) 

b,  LOGOFF 

i.  Final  record  processing 

ii.  Control  record  processing 

iii.  Device  deactivation 
(iv-  User  supplied  extensions) 

c.  SELECT  (user  supplied  comparisons  and/or 
messages) 

d.  RELEASE  (user  supplied  messages) 


e.  ADD/INSEHT 
f-  DELETE 

g.  Record  accessing  (user  supplied  messages) 

h.  Page  accessing  (user  supplied  timing) 

i.  Field  accessing  and  switch  to  update  mode 

j.  Update  cancellation 

3.  Error  reporting  (user  supplied  messages)  and 
user-performance  recording 

III,  Touch  panel  (asynchronous) 

A-  Coordinate  translation  (user  supplied  preprocessing) 

B,  Field  selection 

C,  Field  accessing  (user  supplied  timing)  and  switch 
to  update  mode 

(IV.  Character  writing  (user  supplied  timing)  (asynchronous)) 

V.  Termination 

A.  Drain  I/O  queues 

B.  Device  termination 

(C.  User  supplied  termination) 
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III.  PRIMITIVE  COMMANDS 


1.0  System-  and  File-Oriented  Commands 


LO  -  Logon,  Logoff 


2.0  Fecord-Or iented  Commands 


A, AD  <naffle>  -  Add 


I, IN  <name>  -  Insert 


EX  -  Exclude 

D,DE  -  Delete 
B,BE,RL  -  Release 


add  a  record  of  the  named  type  to  the 
file.  The  record  is  added  Immediately 
after  the  current  record,  or  in  place  of 
the  record  just  deleted  (if  any) ,  or  at 
the  end  of  the  file  if  no  record  has  yet 
been  accessed. 

insert  a  record  of  the  named  type  into 
the  file.  The  record  is  inserted 
immediately  before  the  current  record, 
or  in  place  of  the  record  just  deleted 
(if  any) ,  or  at  the  beginning  of  the 
file  if  no  record  has  yet  been  accessed, 
exclude  the  current  record  from  the 
working  subset. 

delete  the  current  record  from  the  file, 
expand  the  working  subset  to  include  all 
allocated  records. 
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S,SE  (<bexpr>) 


-  Select  -  selects  a  working  subset  of  the  file 
based  on  (Boolean  combinations  of) 
relational  or  logical  values  of  field (s) 
<bexpr>  <bvalue>  |  (<bexpr>)  1 


<bvalue> 


<uop> 

<bop> 

<rop> 


<value> 


<uop><bexpr>  |  <bexpr><bop><bexpr> 

:=  (<name><rop><value>)  |  <naiDe> 

:=  NOT  I 

:=  &  I  AND  I  OB  I  I 

:=  =  I  EQ  I  >  I  GT  I  LT  I  <  I  N£  I  LE  I  GE 

:=  <string>  |  *<string>* 


CB  -  Current  Record  -  access  the  current  record  in  the  working 

subset.  (An  effective  NOP.) 

NB  -  Next  Record  -  access  the  next  record  in  the  working 


subset. 


F,FO  <nuniber> 


"  Forward  -  access  the  nth  subsequent  record  in  the 
working  subset. 

PR  -  Previous  Record  -  access  the  previous  record  in  the  working 

subset. 

B,BA  <number>  -  Back  -  access  the  nth  previous  record  in  the 

working  subset. 

FR  -  First  Record  -  access  the  first  record  in  the  working 

subset. 

LB  -  Last  Record  -  access  the  last  record  in  the  working 

subset. 


3.0  Page-Oriented  Commands 


CP  -  Current  Page 
NP  -  Next  Page 

PP  -  Previous  Page  - 

FP  -  First  Page  - 

LP  -  Last  Page 

P,PA  <name>  -  Page 

P,P&  <number>  -  Page  - 


(re) display  the  current  page, 
display  the  next  page  in  the  current 
record. 

display  the  previous  page  in  the  current 
record. 

display  the  first  page  in  the  current 
record. 

display  the  last  page  in  the  current 
record. 

display  the  page  in  the  current  record 

with  the  given  name. 

display  the  nth  page  in  the  current 

record. 


4.0  Field-Oriented  Commands 


CF  -  Current  Field 

-  access 

the 

current  field  in  the  current 

page. 

NF  -  Next 

Field 

-  access 

the 

next 

field 

in  the 

current  page- 

PF  -  Previous  Field 

-  access 

the 

previous  field  in 

the  current 

page. 

FF  -  First 

Field 

-  access 

the 

first 

field 

in  the 

current 

page. 

LF  -  Last 

Field 

-  access 

the 

last 

field 

in  the 

current  page. 
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<naae> 

<nuBber> 

<touch> 


-  access  the  named  field  in  the  current 
page. 

-  access  the  nth  field  in  the  current  page. 

-  access  the  field  touched  (if  touch 
sensitive) . 


5-0  Special  Key  Functions 


<CTRL-C> 

<CTRL-0> 

<CTRL-Z> 


<rubout> 


-  terminate  execution- 

-  throw  away  the  current  input  line. 

-  when  modifying  a  field,  leave  the  field 
unchanged;  otherwise,  leave  the  current 
record  unchanged. 

-  delete  the  last  character  in  the  current 
line. 
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IV.  FILE  STRUCTUBE 


1.0  Introduction 

A  logical  file  in  the  generic  systen  consists  of  a  physical 
data  file  and  a  physical  status  file.  The  two  files  are  managed 
as  a  single  entity  by  the  generic  system. 

2.0  Data  File 


1 

1 

] 

1 

I 

I 

1 

1 


The  data  file  is  a  random  access  file  in  which  the  data 
associated  with  a  logical  file  is  maintained  by  the  generic 
system.  All  records  in  the  file  are  the  same  size,  each  record 
being  a  multiple  of  256  words.  The  file  consists  of  a  control 
record  followed  by  the  data  records.  The  data  records  consist  of 
two  subsets  of  contiguous  records  (either,  but  not  both,  of  which 
may  be  empty) ;  the  first  subset  are  records  which  are  in  use 
(allocated  or  deleted) ;  the  second  subset  are  records  which  have 
never  been  used. 


2.1  Control  Record 

The  first  physical  record  of  a  data  file  is  reserved  for  the 
maintenance  of  the  file  by  the  generic  system.  The  format  of  the 


record  is  as  follows: 


Word  1  holds  the  number  of  records  in  the  file. 

Word  2  holds  the  physical  record  number  of  the  first  unused  record 
in  the  file. 

Word  3  holds  the  record  size  plus  one  of  the  records  in  the  file. 

Word  4  holds  the  physical  record  number  of  the  first  record  on  the 
allocated  list. 

lord  5  holds  the  physical  record  number  of  the  first  record  on  the 
deleted  list. 

Word  6  holds  the  physical  record  number  of  the  last  record  on  the 
allocated  list. 

Word  7  holds  the  number  of  allocated  records  in  the  file. 

The  remaining  words  are  unused  and  have  undefined  values. 


2.2  Data  Records 

The  first  two  words  of  each  data  record  are  reserved  for  future 
changes  to  the  system.  The  third  word  of  each  data  record 


J 


«HlM 


mmim 
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contains  the  (coded)  record  type  of  the  record.  The  remaining 
words  contain  the  actual  data  associated  with  the  record.  Any 
excess  words  in  the  record,  which  must  be  a  multiple  of  256  words 
in  length,  are  unused  and  have  undefined  values.  All  contents  of 
a  data  record  are  undefined  if  the  record  is  deleted  or  unused. 


3.0  Status  File 

The  status  file  is  organized  as  a  random-access  file  of  256 
word  records.  Each  record's  format  is  identical  to  that  of  the 
STATUS  area,  (described  in  section  V.6)  ,  with  the  exception  that 
the  contents  of  the  final  word  are  unpredictable.  The  allocated 
data  records  are  externally  chained  on  a  doubly-linked  list 
maintained  in  the  STATE!  status  elements  in  the  status  file.  The 
deleted  data  records  are  externally  chained  on  a  singly-linked 
list  of  STATE!  status  elements.  The  included/excluded  status  of 
each  allocated  record  in  up  to  15  working  sets  is  recorded  in  the 
status  file  with  both  deleted  and  unused  records  marked  as  if  they 
were  deleted.  Excess  STATE!  status  elements  in  the  final  record 
of  the  status  file  are  initialized  as  if  for  deleted  records. 
There  is  no  STATE!  status  element  for  the  control  record  of  the 
data  file,  so  the  physical  position  in  the  status  file  of  a  STATS! 
status  element  associates  it  with  the  corresponding  logical 
rather  than  physical  -  record  in  the  data  file. 


V- 


DATA  ORGANIZATION 


1.0  latroduction 

The  structure  of  this  description  of  the  data  organization  is 
the  same  as  the  structure  of  the  data  organization  itself.  Thus 
by  reading  through  linearly,  one  can  see  the  organization  as  a 
whole;  or  one  can  use  the  index  to  go  directly  to  any  block  in 
question.  One  point  to  note  is  that  all  definitions  of  files, 
records,  ai\d  pages  are  kept  in  memory,  and  that  only  the  data  in  a 
given  record  is  swapped  in  and  out.  The  system  is  entirely  table- 
driven,  and  unless  otherwise  noted  all  variables  are  two-bytes  in 
size  (integer) ,  and  all  indices  are  in  units  of  two-bytes. 
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2.0  MEMORY 

MEMORY  is  at  the  same  time  the  name  of  the  universal  array  in 
which  all  system  tables  and  data  are  kept,  and  the  name  of  the 
block  of  nine  words  that  appear  at  the  beginning  of  that  array. 
The  uses  of  those  particular  nine  words  are  as  follows: 

MEMOay(l)  holds  the  index  in  MEMORY  of  the  BUFCTL  area.  It  must 
be  initialized  to  that  value. 

MEMORY  (2)  holds  the  index  in  MEMORY  of  the  CSTATE  area.  Again, 
this  value  must  be  initialized. 

MEMORY  (3)  holds  the  length  of  MEMORY  (as  the  universal  array).  It 
is  needed  only  by  a  debugging  routine  that  dumps  MEMORY,  and  if 
that  routine  (DEFDMP)  is  to  be  used,  MEMORY (3)  must  be  initialized 
to  that  length.  Normally,  however,  this  location  may  be  ignored, 

MEMORY (4)  holds  the  font  width.  It  must  be  given  that  value 
initially. 

MEMORY  (5)  is  currently  unused,  but  is  reserved  for  access  to 

multiple  files. 

MEMORY(6)  is  currently  unused,  but  is  reserved  for  access  to 

multiple  files. 


J 


HEHOBY  (7)  is  currently  unused, 
Bultiple  files. 


but  is  reserved  for  access  to 


MENORY(a)  is 
logical  I/O  un 

MEMORY  (y)  is 
multiple  users 


urrently  unused, 
ts  in  support  of 

urrently  unused. 


but  is  reserved 
multiple  files, 

but  is  reserved 


for  allocation  of 


for  management  of 


a 
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3.0  User  Data 


3.1  CSTATE 


The  system  maintains,  (and  under  a  multi-user  version  would 
maintain  for  each  user) ,  a  block  called  CSTATE,  which  describes 
the  current  user  state.  The  multiple  user  access  arrangement  is 
not  yet  defined.  The  use  of  each  of  the  ten  words  in  CSTATE  are 
as  follows: 


CSTATE(I)  holds  the  physical  record  number  of  the  first  record  on 
the  included  list-  It  is  zero  if  there  are  no  included  records. 


CSTATE{2)  holds  the  physical  record  number  of  the  last  record  on 
the  included  list.  It  is  zero  if  there  are  no  included  records. 


CSTATE  (3)  holds  the  index  in  CSTATE  of  the  user's  ACCBLK,  and 
should  be  initialized  to  that  value- 


CSTATE(4)  holds  the  index  in  MEMOEY  of  the  user's  RECOflD  area,  and 
should  be  initialized  to  that  value. 


CSTATE(5)  holds  the  index  in  HEMOEY  of  FLDSCR-  Under  a  multi-file 
version,  it  would  be  initialized  to  zero,  and  given  the  index 
value  when  a  file  was  first  accessed.  Currently,  it  should  be 
given  the  index  value  initially. 


I  • 


CSTATE(6)  holds  the  index  in  FLDSCR  of  EDESCF.  It  is  given  the 
index  value  vhen  a  record  is  accessed,  and  is  zero  when  no  record 


is  currently  accessed,  Onder  a  multi-file  version,  it  would  be 
zeroed  by  the  system  each  time  a  new  file  was  accessed. 

CST&TE(7)  holds  the  index  in  RDESCB  of  PDESCR.  It  is  zeroed  each 
time  a  record  is  accessed,  and  given  the  index  value  each  time  a 
page  is  accessed. 

CSTATE(8)  holds  the  current  field  number.  It  is  zeroed  each  time 
a  page  is  accessed,  and  assigned  the  field  number  each  time  a 
field  is  accessed. 

CSTATE(9)  holds  the  index  in  MEMORY  of  the  next  CSTATE  area  or 
zero  if  this  is  the  last  CSTATE  area. 

CSTATE<10)  holds  the  working  set  number  currently  in  use.  It  must 
be  initialized  to  zero. 


3.2  ACCBLK 

The  generic  data  transaction  system  maintains  within  this  block 
accomulated  and  current  measurements  of  the  interaction  of  the 
operator  with  the  system.  The  specific  words  are  used  as  follows: 

ACCBLK (1)  holds  the  stroke  count  for  the  most  recently  typed 
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entry- 

ACCBLK(2)  holds  the  rubout  count  for  the  most  recently  typed 
entry. 

ACCBLK(3)  holds  the  line  cancel  count  for  the  most  recently  typed 
entry. 

ACCBLK(4)  holds  the  response  time  of  the  user  to  the  most  recent 
prompt  (in  60  hertz  ticks). 

ACCBLK(5)  holds  the  typing  time  of  the  most  recent  entry  (in  60 
hertz  ticks). 

ACCBLK(6)  holds  the  elapsed  time  of  the  processing  of  the  most 
recent  directive  (in  60  hertz  ticks). 

ACCBLK(7)  holds  the  number  of  commands  processed  by  the  system. 

ACCBLK(8)  holds  the  number  of  errors  processed  by  the  system. 
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4.0  File  Definition  (s) 


In  the  current  impleoentatlon,  there  is  but  one  (logical)  file, 
which  aust  be  accessed  by  the  user  (with  the  procedure  UINITL). 
However  the  data  organization  allows  any  number  of  files  to  be 
defined,  each  definition  being  a  block  as  described  in  this 
section,  multiple  definitions  being  arranged  sequentially  in 
flERORY.  The  multiple  file  access  arrangement  is  not  yet  defined. 


4.1  FLDSCF 


The  file  descriptor,  FLDSCS,  is  a  block  of  twelve  words  which 
are  used  as  follows: 


FLDSCR(I)  holds  the  index  in  FLDSCR  of  PNDSCB.  It  must  be 
initialized  to  that  value. 


FLDSCR (2)  holds  the  index  in  FLDSCR  of  RTTABL.  Again,  this  value 
must  be  initialized. 


FLDSCR (3)  holds  the  maximua  number  of  records  in  the  file, 
including  the  control  record,  deleted  records,  and  unused  records. 
The  value  is  extracted  from  the  file  control  record  when  the  file 
is  opened. 


FLDSCR (4)  holds  the  physical  record  number  of  the  first  unused 
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record  in  the  file.  The  value  is  extracted  from  the  file  control 
record  when  the  file  is  opened.  If  there  are  no  unused  records, 
this  location  equals  FLDSCB  (3) ♦ 1. 

FLDSCB(5)  holds  the  record  size  plus  one  of  records  in  the  file, 
and  must  be  appropriately  initialized. 

FLDSCE{6)  holds  the  physical  record  number  of  the  first  record  on 
the  allocated  list.  It  is  zero  if  there  are  no  allocated  records. 
The  value  is  extracted  from  the  file  control  record  when  the  file 
is  opened. 

FLDSCR(7)  holds  the  physical  record  number  of  the  first  record  on 
the  deleted  list.  It  is  zero  if  there  are  no  deleted  records. 
The  value  is  extracted  from  the  file  control  record  when  the  file 
is  opened. 

FL0SCR(3)  holds  the  physical  record  number  of  the  last  record  on 
the  allocated  list.  It  is  zero  if  there  are  no  allocated  records. 
The  value  is  extracted  from  the  file  control  record  when  the  file 
is  opened. 

FLDSCR(9)  is  the  number  of  allocated  records  in  the  file.  The 
value  is  extracted  from  the  file  control  record  when  the  file  is 
opened. 


FLDSCR(IO)  holds  the  physical  record  number  of  the  file  status 
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record  currently  in  the  STATUS  area. 

FLDSCK(II)  holds  the  index  in  MEdOPY  of  the  STATUS  area  for  the 
file.  It  should  be  initialized  to  zero. 

FLDSCR(12)  is  currently  unused,  but  is  reserved  for  accessing 
■ultiple  working  sets. 


4.2  BNOSCP 

BNOSCB  is  a  block  of  two  words  describing  the  record  name 
symbol  table,  a  combination  of  BNTABL  and  PNIdAG. 

RHDSCB(1)  holds  the  index  in  BNDSCR  of  HNIMAG,  or  zero  if 
RNDSCB(2)  is  zero. 

BNDSCP(2)  holds  the  number  of  record  names  in  the  table. 


4.3  BNTABL 

BNTABL  and  BNINAG  together  constitute  the  record  name  symbol 
table.  BNTABL  describes  the  name  images  in  BNINAG,  and  holds  the 
record  type  for  each  record  name.  A  record  type  nay  be  unnamed, 
have  one  or  many  names. 
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BIIT&BL(1,n)  holds  the  (coded)  record  type.  Record  types  are 
(coatiguous)  positive  integers  used  as  indices  into  BTTABL. 

BHTABL(2,n)  holds  the  index  in  RNIMAG  of  the  (first  two  characters 
of  the)  nth  record  name. 

BNTABL(3,n)  holds  the  length  in  characters  of  the  nth  record  name- 

4.4  BNIHAG 

RNIHAG  is  a  packed  string  of  record  type  names.  Each  name  is 
begun  on  a  word  boundary* 


4,5  RTTABL 

RTTABL,  the  record  type  table,  links  a  record  type  with  its 
BOB SCR. 

RTTABL(n)  holds  the  index  in  FLDSCE  of  the  RDESCR  for  record  type 
Qunber  n. 


4.6  Record  De£inltioa(s) 


Record  definitions  are  repeatable  within  a  given  file 


definition,  just  as  file  definitions  are  repeatable  within  MEMORY, 
Multiple  record  definitions  are  concatenated  at  this  point  in  the 
file  definition,  and  are  located  through  RTTABL. 

h.6.  1  RDBSCR 

The  record  descriptor,  EDESCR,  is  a  block  of  five  words  which 
are  used  as  follows: 

RDESCR(1)  holds  the  index  in  EDESCR  of  the  first  PDESCE. 

RDBSCR (2)  holds  the  index  in  EDESCR  of  SMDSCB. 

BDESCRO)  holds  the  index  in  EDESCR  of  FORMAT. 

RDBSCR {«)  holds  the  index  in  RDESCR  of  DDESCR, 

BDESCB(5)  holds  the  index  in  RDESCR  of  PGDSCR. 

4.6,2  SHDSCR 

SHOSCR  is  a  block  of  two  words  describing  the  field  name  symbol 
table,  a  combination  of  SNTABL  and  STHAGE. 

SNDSCR(I)  holds  the  index  in  SHDSCR  of  SIHAGE,  or  zero  if 
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S{1DSCB(2)  is  zero. 


SN0SCIi(2)  holds  the  nuaber  of  synbols  in  the  table. 


4.6.3  SMTABL 

SHTABL  and  slM&GE  together  constitute  the  field  name  symbol 
table.  SMTABL  describes  the  name  images  in  SIWAGE,  and  points  to 
the  entry  in  DTABLE  for  each  field  named.  Fields  may  have  no 
name,  one,  or  many  names. 

SMTABL(1,n)  holds  the  index  (second  subscript)  of  the  entry  for 
the  field  in  DTABLE. 

SNTABL(2,n)  holds  the  index  in  SIMAGE  of  the  (first  two  characters 
of  the)  nth  field  name. 

Sf!TABL(3,n)  holds  the  length  in  characters  of  the  nth  field  name. 


4.6.4  SIMAGE 

SIMAGE  is  a  packed  string  of  field  names.  Each  name  is  begun 
on  a  word  boundary. 


fiitiTiiiiiii  i'rMri#il(  mafi ■ 
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4.6.5  DOESCR 

DDESCR  is  one  word  describing  DTABLE. 

DDESCR(I)  holds  the  number  of  fields  described  in  DTABLE,  i-e-, 
the  length  of  DTABLE. 

4.6.6  DTABLE 

There  is  one  entry  in  DTABLE  for  each  unique  field  in  a  record. 
(A  given  field,  social  security  number  for  example,  might  appear 
on  several  pages  of  the  same  record.)  It  points  to  the  DATA 
entry,  and  describes  how  the  data  is  displayed,  for  each  field. 

DTASLE(1,n)  holds  the  index  in  DATA  of  the  current  contents  of  the 
field. 

DTABLE  (2, n)  holds  the  word  length  of  the  field  contents  in  DATA. 

DTABLE(3,n)  holds  the  index  in  FOFUAT  of  the  display  format  of  the 
field. 

DTABLE(4,n)  holds  the  character  (byte)  length  of  the  echo  area  for 
the  field.  If  the  field  length  is  longer  than  the  echo  length. 


the  extra  characters  are  written  over  the  last  position  in  the 
echo  field.  This  length  must  include  room  for  the  blank  which  is 


prefixed  to  all  printed  fields 


0TiBLE(5,n)  is  currently  unused,  but  is  reserved  for  password 
access  to  the  field. 

DTABLE(6,a)  contains  a  non-zero  flag  which  is  passed  to  an 
application  specific  UCHECK  (user  check)  routine,  to  verify  the 
correctness  of  a  new  value  being  giver  to  the  field.  A  zero  flag 
indicates  that  no  verification  is  required. 


4.6.7  FORMAT 

FORMAT  is  a  packed  string  of  format  images  for  the  data  for 
each  field  in  DTABLE,  Each  object  time  format  string  is  begun  on 
a  word  boundary.  The  display  of  blank  fields  is  suppressed  unless 
a  blank  precedes  the  left  parenthesis  In  the  format  string. 


4.6.8  PGDSCR 

PGDSCR  is  a  block  of  two  words  describing  the  page  name  symbol 
table,  a  combination  of  PGTABL  and  PGIHAG. 

PGDSCR(I)  holds  the  index  in  PGDSCR  of  PGIHAG,  or  zero  if 
PGDSCR  (2)  is  zero. 
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PG0SCR(2)  holds  the  number  of  symbols  in  the  table. 

4-6.9  PGTABL 

PGTABL  and  PGIMAG  together  constitute  the  page  name  symbol 
table.  PGTABL  describes  the  name  images  in  PGIMAG,  and  holds  the 
page  number  for  each  name.  Pages  may  have  no  name,  one,  or  many 
names. 


PGTABL(1,n)  holds  the  page  number  for  the  nth  page  name. 

PGTABL(2,n)  holds  the  index  in  PGIMAG  of  the  (first  two  characters 
of  the)  nth  page  name. 

PGTABL(3,n)  holds  the  length  in  characters  of  the  nth  field  name. 

4.6.10  PGIMAG 

PGIMAG  is  a  packed  string  of  page  names.  Each  name  is  begun  or. 
a  word  boundary. 

4.6.11  Page  Def inition (s) 

Page  definitions  are  repeatable  within  a  given  record 
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definition  -  just  as  record  definitions  are  repeatable  aithin  file 
definitions  -  multiple  page  definitions  being  concatenated  at  this 
point  in  the  record  definition.  The  first  page  definition  is 
located  through  aOESCR,  and  subsequent  ones  are  found  by 
traversing  the  links  in  the  PDESCR  for  each  page. 


4.6.11.1  PDESCR 

The  page  descriptor,  PDESCR,  is  a  block  of  six  words  which  are 
used  as  follows: 

PDESCR(I)  holds  the  page  number. 

PDESCB(2)  holds  the  index  in  RDESCR  of  the  PDESCR  for  the  next 
page.  A  value  of  zero  indicates  no  next  page. 

PDESCR (1)  holds  the  index  in  RDESCR  of  the  PDESCR  for  the  previous 
page.  A  value  of  zero  indicates  no  previous  page, 

PDESCR (4)  holds  the  index  in  PDESCR  of  SDESCR, 

PDESCR(5)  holds  the  index  in  PDESCR  of  TDESCR. 


PDESCR (6)  holds  the  index  in  PDESCR  of  FDESCR 


29 


4.6.11.2  TDESCE 

TDSSCR  is  a  single  word  describing  TTABLE. 

TDESCR(I)  holds  the  number  of  touch  areas  defined  in  TTABLE,  i.e., 
the  length  of  TTABLE. 


4.6.11.3  TTABLE 

Each  entry  in  TTABLE  defines  one  touch  area  for  the  page. 
There  may  be  no,  or  any  number  of,  touch  areas  defined. 

TTABLE(1,n)  holds  the  index  (second  subscript)  in  FTABLE  of  the 
field  referenced  by  a  touch  in  area  n, 

TTABLE(2,n)  holds  the  x  screen  coordinate  of  the  upper  left  corner 
of  touch  area  n. 

TTABLE(3,n)  holds  the  y  screen  coordinate  of  the  upper  left  corner 
of  touch  area  n. 

TTABLE  (4, n)  holds  the  x  screen  coordinate  of  the  lower  right 

corner  of  touch  area  n. 

TTABL£(5,n)  holds  the  y  screen  coordinate  of  the  lower  right 


corner  of  touch  area  n. 
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4.6.11,4  FDESCE 


FDESCR  is  a  single  word  describing  FTABLE, 

FDBSCE(I)  holds  the  number  of  fields  on  the  page,  which  is  also 
the  length  of  FTABLE.  A  page  may  contain  no  fields. 

4.6.11.5  FTABLE 

There  is  one  entry  in  FTABLE  for  each  field  on  the  page.  It 
gives  the  position  on  the  page,  and  a  pointer  to  the  description 
of  the  data,  for  each  field.  Note  that  a  blank  is  prefixed  to  all 
printed  fields, 

FTABLE (1,n)  holds  the  index  (second  subscript)  in  DTABLE  for  field 
number  n. 

FTABLE(2,n)  holds  the  x  screen  coordinate  of  the  lower  left  corner 
of  the  first  print  position  in  the  field. 

FTABLE  (3, n)  holds  the  y  screen  coordinate  of  the  lower  left  corner 
of  the  first  print  position  in  the  field. 
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■  4.6.11.6  SDESCB 

^  SDESCE  is  a  block  of  two  words  describing  SSTABL  and  SSTRNG, 

I  which  together  define  the  static  elements  of  the  page. 

I  SDESCR(I)  holds  the  index  in  SDESCR  of  SSTRNG,  or  zero  if 

I  SDESCR(2)  is  zero. 

I  SDESCB(2}  holds  the  number  of  entries  (commands)  in  SSTABL.  This 

table  may  be  empty. 

I 

*  4.6.11.7  SSTABL 


I 

Each  entry  in  SSTABL  is  a  command  to  either  1)  move  the  pointer 
j  to  a  given  position  on  the  screen,  or  2)  draw  a  line  from  the 

current  pointer  position  to  a  given  position,  (leaving  the  pointer 
at  the  end  position) ,  or  3)  to  write  at  a  given  position  one  of 
the  character  strings  in  SSTRNG. 


SSTABL(1,n)  holds  the  x  screen  coordinate  of  the  target  point. 

SSTABL  (2, n)  holds  the  y  screen  coordinate  of  the  target  point. 

SSTABL(3,n)  may  have  any  of  the  following  values:  1)  zero,  which 
commands  that  the  pointer  be  moved  to  the  target  point;  2)  two, 
which  commands  that  a  line  be  drawn  from  the  current  pointer 
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position  to  the  target  point;  or  3)  minus  the  index  in  SSTfiNG  of 
(the  first  two  characters  of)  a  string  to  be  written  on  the 
screen,  with  the  target  point  being  the  position  of  the  lower  left 
corner  of  the  first  character- 


4.6,  11-8  SSTBNG 

SSTRNG  is  a  packed  string  of  static  character  strings  for  the 
page.  Each  string  is  begun  on  a  word  boundary,  and  must  be 
terminated  by  a  zero  byte. 


5.0  Data  Record  I/O  Areas 


Storage  must  be  reserved  at  this  point  for  the  data  record  I/O 
areas.  A  single  data  record  I/O  area  must  be  provided  for  each 
user.  Since  all  indexing  is  relative  to  the  data  record  I/O  area 
referenced  by  CSTATE(4)  for  the  current  user,  only  the  format  of 
one  (the  first)  relocatable  data  record  I/O  area  is  described. 


5.1  RECORD 

RECORD  is  a  block  of  five  words  containing  information,  used 
and  maintained  by  the  system,  about  the  record  whose  data  is 
currently  in  the  DATA  area  immediately  following  RECORD.  The  last 
three  words  of  RECORD  are  the  first  three  of  the  physical  block  of 
data  for  the  record. 

RECORD  (1)  holds  a  flag  indicating  whether  or  not  changes  have  been 
made  to  the  record  since  it  was  last  read  into  memory  (or  saved). 
A  value  of  one  indicates  change,  zero  indicates  none. 

BECORD(2)  holds  the  seguential,  physical  record  number  of  the 
record  in  its  physical,  direct  file.  Zero  indicates  that  no 
record  has  been  accessed  from  the  current  file. 


RECORD(3)  holds  the  physical  record  number  of  the  next  logical 
record  on  the  allocated  list. 


34 


BEC0BD(4)  holds  the  physical  record  number  of  the  previous  logical 
record  on  the  allocated  list. 

BEC0BD(5)  holds  the  (coded)  record  type  of  the  record.  A  positive 
value  is  the  index  (second  subscript)  of  the  entry  for  this 
record’s  type  in  BTTABL.  A  value  of  zero  indicates  that  the 
record  has  been  permanently,  logically  deleted  from  the  file. 

5.2  DATA 


DATA  is 

a  concatenated 

string  of  the  data 

currently 

in  the 

record. 

Each  data  item 

is 

begun  on  a  word 

boundary. 

All 

templates 

for  describing 

the 

data  arrangements 

of  the 

various 

record  data  types  for  all 

of 

the  files  must  be 

specified  using 

this  same 

addressing  origin 

• 

6.0  Status  Record  I/O  Areas 


Storage  aay  be  reserved  at  this  point  for  any  number  of  status 
record  I/O  areas,  which  are  allocated  for  I/O  using  a  least- 
recently-used  (LRU)  algorithm-  It  is  suggested  that  at  least  four 
status  record  I/O  areas  be  provided  for  each  file  or  each  user 
(whichever  are  fever). 


6.1  STATUS 

STATUS  is  a  status  record  I/O  area.  It  contains  a  single, 
three-word  status  element  (STATEL)  for  each  data  record  in  the 
logical  file.  STATUS  is  256  words  long,  and  contains  85  status 
elements.  The  final  word  of  STATUS  is  set  to  indicate  that  the 
status  record  has  been  modified  and  must  be  written. 


6.2  STATEL 

Each  STATEL  status  element  is  used  to  maintain  the  status  and 
links  of  a  single  data  record.  All  STATEL  are  initialized  by  the 
file  creation/aaintenance  utility,  and  are  of  the  following 
fornat: 

STATEL (1)  holds  the  status  of  the  nthti  physical  record  in  the 
data  file,  where  n  is  the  status  element's  sequential  position  in 


36 


the  status  file.  A  value  of  -1  implies  that  the  data  record  is 
either  deleted  or  unused;  any  other  value  implies  the  record  is 
allocated.  When  STATEL(I)  indicates  the  data  record  is  allocated, 
the  data  record's  status  in  the  working  set  indexed  by  CSTATE(IO) 
is  determined  by  testing  the  bit  zero-indexed  from  the  least 
significant  bit  by  CSTATE(IO).  If  the  bit's  value  is  zero,  the 
data  record  is  included  in  the  corresponding  working  set;  a  value 
of  1  means  the  record  is  excluded.  (For  example,  if  STATEL(1)=5, 
the  corresponding  data  record  is  excluded  from  the  first  and  third 
working  sets  only.) 

STATEL(2)  holds  the  physical  record  number  of  the  data  record  next 
on  the  same  list  (i.e. ,  either  allocated  or  deleted).  If  the  data 
record  is  unused,  i.e.  is  on  neither  list,  the  value  of  this 
location  is  meaningless. 

STATBL(3)  holds  the  physical  record  number  of  the  data  record 
previous  on  the  allocated  list.  If  the  record  is  not  allocated, 
the  value  of  this  location  is  meaningless. 
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7.0  BOFFEB  CONTROL 

BOFCTL  and  BUFTBL  together  oake  up  the  control  structure  for 
the  least-recently-used  (LBU)  management  of  the  multiple  buffers 
in  the  STATUS  area. 


7.1  BUFCTL 

The  three  vords  in  BOFCTL  are  defined  and  must  be  initialized 
as  follows: 

BUFCTL(I)  holds  the  index  in  BUFCTL  of  the  control  element  for  the 
newest  buffer  in  STATUS. 

BOFCTL (2)  holds  the  index  in  BOFCTL  of  the  control  element  for  the 
oldest  buffer  in  STATOS. 

BUFCTL(3)  holds  the  index  in  BOFCTL  of  the  control  element  of  the 
most  recently  allocated  dedicated  buffer  in  STATUS.  It  must  be 
initialized  to  zero. 


7.2  BUFTBL 

BUFTBL  contains  one  control  element  for  each  of  the  multiple 
buffers  in  the  STATUS  area.  A  BUFTBL  element  is  defined  and  must 


tm 
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be  initialized  as  follows: 


BDFTBL(1,n)  holds  the  index  in  BUFCTL  of  the  control  element  for 
the  next  older  buffer  in  STATOS. 


B0FTBL(2,n)  holds  the  index  in  BUFCTL  of  the  control  element  for 
the  next  newer  buffer  in  STATOS. 


B0FTBL(3,n)  holds  the  index  in  MEMORY  of  the  buffer  in  STATOS 
controlled  by  the  element. 


BUFTBL(4,n)  holds  the  number  of  words  in  a  status  file  record  to 
be  rewritten  and  must  be  initialized  to  zero. 


BUFTBL(5,n)  holds  the  disk  unit  on  which  the  status  file  block 
will  reside  and  must  be  initialized  to  zero. 


BUFTBL(6,n)  holds  the  file  block  number  of  the  status  file  block 
and  must  be  initialized  to  zero. 
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VI.  COMMON  BLOCKS 

Host  communication  between  procedures  is  accomplished  through 
argument  lists,  but  in  a  few  special  cases  common  blocks  are  used. 
For  a  description  of  how  to  tailor  these  common  blocks  for  a 
specific  application,  please  see  the  User's  Guide.  All  common 
blocks  except  2TOOCH  will  be  merged  into  other  parts  of  ZMEHHY 
with  the  expansion  to  multiple  users. 

ZFLAGS 

FIELD  “  if  one,  indicates  that  a  field  has  been  addressed  and  a 
field  update  needs  to  be  done;  is  zero  otherwise. 

RECCNT  -  the  count  of  records  in  the  working  set  (included 
list)  . 

OLDTIM  -  the  low  order  value  of  the  system  clock  when  the  last 
command  was  entered. 

LOGTOG  -  if  one,  indicates  that  the  user  has  executed  a  LOGON 
command;  -1  initially  and  after  the  execution  of  a  LOGOFF 
command. 

Used  by  Procedures:  ADD,  BLOCK  DATA,  CMNDEX,  CHNDXl,  CHNDX2, 
ENDTIH,  FLDUPD,  (main),  BELEAS,  BEHOVE,  SAMPLE,  TPANEl, 
HHAPDP 

ZLOC 

CHHD  -  y  coordinate  of  command  echo  position;  (x  coordinate 


=  0) ;  nay  have  any  value  16n,  0  <=  n  <=  31 
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DIAG  -  y  coordinate  of  diagnostics  echo 
nate  =  0)  ;  nay  have  any  value  16n,  0 
X1,Y1,X2,y2  -  coordinates  of  diagonally 
the  input  echo  Hindow;  each  may  have 
0  <=  n  <=  511. 

Used  by  Procedures;  BLOCK  DATA,  ERROR, 


position;  (x  coordi 
<=  n  <=  31. 
opposite  corners  of 
any  value  n, 

(main) ,  MESSAG,  SDISPL 


ZHEHRY 

MEMORY  -  see  section  III.  1.1. 

Used  by  Procedures;  FLDOPD,  (main),  SCAN,  TPANEL,  HPAPUP 


ZTOUCH 

This  common  block  is  used  to  pass  touch  coordinates  from  the 
device  handler  to  TPANEL,  which  handles  the  touch  pseudo-commands. 
X,Y  -  coordiantes  of  touch;  each  may  have  any  value  n, 

0  <*  n  <=  31. 

Used  by  Procedures:  TPANEL 


ZUMIT 

UNIT  -  the  disk  unit  on  which  record-data  blocks  reside. 

PUNIT  -  the  plasma  panel. 
lUNIT  -  the  keyboard. 

SUMIT  -  the  disk  unit  on  which  the  file  status  blocks  reside. 
Used  by  Procedures:  BLOCK  DATA,  DATAIO,  ERROR,  FDISPL,  INITL, 
(main),  MESSAG,  RITE,  SELERR,  SELER1,  SELER2,  STATIO,  WRAPUP 
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VII.  PROCEDURE  DESCRIPTIONS 


ADO 

This  function  adds  a  new  record  to  the  current  file,  inserting 
it  optionally  before  or  after  the  current  record  in  the  allocated 
list,  and  accesses  it  so  that  data  may  be  entered. 

Common  Blocks  Used:  ZFLA6S 
Called  by:  CHNDX1 

Calls:  DATAIO,  GETPTR,  GETREC,  INSTAL,  LOOKUP,  STATUS 

AKGET  (assembly) 

This  subroutine  is  used  to  extract  the  operator  performance 
measurements  from  the  device  handler. 

Called  by:  SAMPLE 
Calls: 

AKSET  (assembly) 

This  subroutine  is  used  to  specify  a  synchronous  extension  to 
the  plasma  panel  character  generator  for  time  delay  purposes. 
Called  by;  INITL 


Calls: 


ARITH 


This  function  perforas  an  arithmetic  comparison  of  input 
(character)  data  with  stored  data. 

Called  by:  COHPAR 
Calls: 

BLOCK  DATA 

BLOCK  DATA  initializes  the  common  blocks  /FLAGS/  ZLOC,  and 
ZONIT. 

Common  Blocks  Used:  ZFLAGS,  ZLOC,  ZONIT 

BOOLN  (assembly) 

This  function  evaluates  boolean  expressions  (from  tables 
generated  by  BSCAN  and  HECTST). 

Called  by:  SELECT 
Calls; 

BSCAN 

This  function  performs  syntax  analysis  of  (complex)  relational 
expressions. 

Called  by:  SELECT 
Calls;  SYMBOL/  TOKEN 


BOFGET 


This  subroutine  removes  a  buffer  control  element  from  the 
doubly-linked  L£U  queue. 

Called  by:  STATIC 
Calls: 

BUPPaT 

This  subroutine  installs  the  most  recently  used  buffer  control 
element  onto  the  doubly-linked  LED  queue. 

Called  by:  STATIC 
Calls: 

BUf HBT 

This  subroutine  physically  writes  a  buffer  if  it  is 
appropriately  flagged  in  its  buffer  control  element. 

Called  by:  STATIC 
Calls: 

BULK  (assembly) 

This  subroutine  erases  (or  writes)  solid,  rectangular  blocks  on 
the  plasma  screen. 

Called  by:  ERASE,  INITL,  LOGOFF,  LOGON,  SDISPL 


Calls: 
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CHNDEX 

This  subroutine  drives  execution  of  the  command  primitives. 

Common  Blocks  Used:  ZFLAGS 

Called  by:  SCAN 

Calls:  CMNDXl,  CMNDX2,  EaROR 

CHNDIN 

This  function  scans  an  input  string  to  determine  what  command 
primitive  (if  any)  the  string  contains. 

Called  by:  SCAM 
Calls:  TEXT 

CMNDX1 

This  subroutine  drives  the  excution  of  all  record-oriented 
command  primitives. 

Common  Blocks  Used:  ZFLAGS 
Called  by:  CNNDEX 

Calls:  ADD,  DATAIO,  ERROR,  GETPAG,  GETREC,  LOGOFF,  LOGON, 

HESSAG,  PDISPL,  RELEAS,  REMOVE,  SELECT,  VALUE 


CriNDX2 

This  subroutine  drives  the  execution  of  all  page-  and  field- 
oriented  command  primitives. 

Common  Blocks  Used:  ZFLAGS 
Called  by;  CHNDEX 

Calls:  ERROR,  FLDNAM,  GETFLD,  GETPAG,  PAGNAtt,  PDISPL,  VALUE 
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COSPAB 

This  function  evaluates  the  truth  or  falsity  of  relational 
expressions  passed  to  it. 
called  by:  RECTST 
Calls:  ARITH,  MATCH 

CONOFF 

This  subroutine  disables  all  keyboard  input  from  the  system 
console. 

Called  by:  INITL 
Calls: 

CON  ON 

This  subroutine  re-enables  the  keyboard  input  from  the  system 
console. 

called  by:  WEAPUP 
Calls: 


CVT 

This  function  converts  an  input  character  string  to  internal 
integer  format. 

called  by;  VALOE 
calls: 


CVTFLD 

This  function  converts  and  copies  an  entered  string  into  its 
assigned  record  data  field. 

Called  by:  FLDOPD 
Calls: 

DATAIO 

This  subroutine  performs  data  record  read/vrite  operations. 
Coamon  Blocks  Used:  ZUNIT 

Called  by:  ADD,  CMNDX1,  GF.TREC,  LOGOFF,  LOGON 
Calls: 

DISPLA  (assembly) 

This  subroutine  draws  lines  on  the  plasma  screen  or  simply 
Boves  the  graphics  cursor. 

Called  by:  SDISPL 
Calls: 

ELINE  (asseably) 

This  subroutine  moves  the  write-position  on  the  plasma  screen 
to  the  beginning  of  a  given  horizontal  line  (on  a  multiple  of 
sixteen  boundary). 

Called  by:  (main) ,  EBBOR,  NESSAG 


Calls: 


ENDTIM 


This  subroutine  updates  the  current  user's  user-perf or mance 
data  area  with  the  elapsed  execution  time  (in  6OH2  clock  ticks)  of 
the  most  recent  directive. 

Common  Blocks  Used:  ZFLAGS 
Called  by:  (main) 

Calls:  TDIF,  TIHGET 

ERASE 

This  subroutine  erases  a  line  of  text  on  the  display  screen. 
Called  by:  (main) ,  EEBOE,  MESSAG 

Calls:  BULK 

ERROR 

This  subroutine  writes  (or  causes  to  be  written)  all  error 
messages. 

Common  Blocks  Used:  ZLOC,  ZUNIT 

Called  by:  CMNDEX,  CMNDXl,  CMNDX2,  FLDUPD,  SCAN 
Calls;  ELINE,  ERASE,  SELERR,  UEREOE 

FDISPL 

This  subroutine  writes  one  or  all  dynamic  elements  of  a  page. 

Common  Blocks  Used:  ZUNIT 

Called  by:  PDISPL 

Calls:  HOVCUR,  BITE,  TIHE 


PLDNAN 


as 


This  function  accesses  the  field  of  the  current  page  with  a 
given  name. 

Called  by:  CMMDX2 
Calls:  GETFLD,  SLOOK 

FLDUPD 

This  subroutine  checks  the  validity  of  a  new  field  value,  and 
drives  the  rest  of  the  field  update  process. 

Common  Blocks  Used:  ZFLAGS,  ZMBMKY 
Called  by:  (main) 

Calls:  CVTFLD,  ERROR,  PDISPL,  UCUECK 

GETBIT 

This  function  returns  the  included/excluded/deleted  status  of  a 
record. 

Called  by:  GETKEC,  INSTAL,  RELEAS 
Calls:  lAMD,  ISHFTL,  ISHFTR,  STATUS 

GETPLD 

This  function  moves  the  cursor  to  the  next  field,  previous 
field.  Last  field,  or  field  number  n,  of  the  current  page. 

Called  by:  CHN0X2,  PLDMAn 
Calls:  MOVeUR 


- 
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GETPAG 

This  function  displays  the  next  page,  previous  page,  last  page, 
or  page  number  n,  of  the  current  record, 
called  by:  CKNDX1,  CMNDX2,  PAGNAfl 
Calls: 

GETPTH 

This  function  returns  the  physical  record  number  of  the  record 
next  or  previous  on  the  allocated  list. 

Called  by:  ADD,  GETPEC,  INSTAL 
Calls:  STATUS 

GETPEC 

This  function  accesses  the  first  record,  next  record,  previous 
record,  nth  subsequent  record,  nth  previous  record,  or  the  last 
record  in  the  current  file. 

called  by:  ADD,  CfINDXI,  REMOVE,  SELECT 
Calls:  DATAIO,  GETBIT,  GETPTR,  HES5AG 

lAND  (assembly) 

This  function  returns  the  bit  by  bit  "and”  of  all  its 
arguments. 

Called  by;  GETBIT,  PUTBIT 
Calls: 
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INITL 

This  subcoutine  establishes  file  definitions. 

CoBfflon  Blocks  Used:  ZUNIT 
Called  by:  (nain) 

Calls:  AKSET,  BULK,  CONOFF,  UINITL,  OTSHA 

INSTAL 

This  subroutine  links  a  ne*  record  into  the  allocated  list. 

Called  by;  ADD 

Calls:  GET3IT,  GETPTE,  PUTPTB 

lOH  (assembly) 

This  function  returns  the  bit  by  bit  ”or*'  of  all  its  arguments. 

called  by:  PUTBIT 

Calls: 

ISHFTL  (assembly) 

This  function  returns  the  specified  left  shift  of  a  value. 

Called  by:  GETBIT,  PUTBIT 

Calls: 

ISHFTB  (assembly) 

This  function  returns  the  sjtecified  right  shift  of  a  value. 
Called  by:  GETBIT 


Calls 
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LOGOFF 

This  subroutine  erases  the  plasma  screen,  deactivates  the  touch 
panel,  updates  the  file  control  record,  and  saves  the  current 
record  if  it  has  been  changed.  (It  also  prevents  further  use  of 
the  system  by  the  current  user  until  a  LO  command  is  executed.) 
Called  by:  CMNDX1,  WRAPOP 
Calls:  BULK,  DATAIO,  STATUS,  TOUCH,  ULOG 

LOGON 

This  subroutine  initializes  the  included  list,  erases  the 
plasma  screen,  and  activates  the  touch  panel.  (It  also  enables 
use  of  the  system  by  the  current  user.)  The  system  is  left  in  the 
no-record-yet-accessed  condition. 

Called  by:  CMNDX1 

Calls:  BULK,  DATAIO,  MESSAG,  OFFTP,  RELEAS,  TOUCH,  ULOG 

LOOKUP 

This  function  performs  a  standard  symbol-table  look-up. 

Called  by:  ADD,  PAGNAM,  BECTST,  SLOOK 
Calls:  HATCH 
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(fflain) 

This  procedure  first  calls  INITL  to  initiali7e  the  files;  then 
loops  to  pick-up  entered  strings  and  call  CHNDEX  or  FLDUPD  as 
appropriate. 

Common  Blocks  Used:  ZFLAGS,  ZLOC,  ZHEHBY,  ZUNIT 
Called  by:  (monitor) 

Calls:  ELINE,  ENDTIM,  ERASE,  FLDUPD,  INITL,  OFPTP,  ONTP, 

PNWAIT,  SAMPLE,  SCAN,  UPEMPT 


HATCH 

This  function  compares  two  character  strings  of  equal  length 
for  equality. 

Called  by:  COMPAR,  LOOKUP,  SYMBOL,  TOKEN 
Calls: 

HESSAG 

This  subroutine  writes/erases  informative  messages. 

Common  Blocks  Used:  ZLOC,  ZUNIT 

Called  by;  CHNDXI,  GETREC,  LOGON,  SELECT 

Calls:  ERASE,  ELINE,  UMSG 

novcUB  (assembly) 

This  subroutine  moves  the  I/O  cursor  to  a  specified  screen 
location. 

Called  by:  FDISPL,  GETFLD,  TPANEL 
Calls: 
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MOT  (assenbly) 

This  function  returns  the  bit  by  bit  cooplement  of  a  value. 

Called  by:  PUTBIT 

Calls: 

OFFTP  (assembly) 

This  subroutine  inhibits  touch  panel  interrupts. 

Called  by:  LOGON,  (main) 

Calls: 

ONTP  (assembly) 

This  subroutine  arms  the  touch  panel  for  further  interrupts. 
Called  by:  (main) 

Calls: 

OTSHA  (assembly) 

This  subroutine  is  used  to  control  object  time  system  work  area 
allocations. 

Called  by:  INITL 
Calls: 

PAGNAN 

This  function  causes  the  display  of  the  page  (of  the  current 
record)  having  a  given  name. 

Called  by:  cnN0X2 
Calls;  GETPAG,  LOOKUP 


POISPI 


This  subroutine  causes  to  be  written  on  the  plasna  screen 
either  an  entire  page,  or  the  dynanic  part  of  eithe  an  entire 
page  or  a  single  field. 

Called  by:  CNMDX1,  CHIiDX2,  FLDOPO 
Calls:  FDISPL,  SDISPL 

PNKILL  (assembly) 

This  subroutine  disables  any  active  output  operations  to  the 
plasna  panel. 

called  by:  WBAPOP 
Calls: 

PMliilT  (assembly) 

This  subroutine  waits  for  all  queues  on  the  plasma  panel  to 
quiesce. 

Called  by:  (main) ,  TIRE,  TPAHEL,  BRAPOP 
Calls: 

POTBIT 

This  subroutine  updates  the  included/ezcluded/deleted  status  of 
a  record. 

Called  by:  BELBAS,  BBHO?B 

Calls:  lAHO,  lOR,  ISHFTL,  MOT,  STATUS 
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PUTPTR 

This  subroutine  updates  the  pointer  to  the  record  next  or 
previous  on  the  allocated  list- 
Called  by:  INSTAL,  REMOVE 
Calls:  STATUS 

PHHITE  (asse  mbly) 

This  subroutine  vrites  a  given  character  string  at  a  given 
location  on  the  plasma  screen. 

Called  by:  SDISPL 
Calls: 

RECTST 

This  subroutine  examines  the  current  record  to  evaluate  the 
truth  or  falsity  of  relational  expressions  passed  to  this 
subroutine  in  tabular  form. 

Called  by:  SELECT 

Calls:  COMPAR,  LOOKUP,  OTEST 

RELEAS 

This  function  puts  all  allocated  records  (in  the  current  file) 
in  all  working  sets. 

Common  Blocks  Used:  ZFLAGS 
Called  by:  CMNDX1,  LOGON 
Calls:  GETBIT,  PUTBIT 
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BEHOVE 


This  function  removes  the  current  record  from  the  current 
working  set,  and  depending  on  the  value  of  an  input  flag,  may 
delete  the  record  from  the  file  as  well.  The  system  is  left  in 
the  no- record-accessed  condition. 

Common  Blocks  Used:  ZFLAGS 
Called  by:  CMNDXI,  SELECT 
Calls:  GEIREC,  PUTBIT,  POTPTP 

BITE 

This  subroutine  is  called  only  by  FDISPL,  and  exists  solely  so 
that  the  write  of  each  field  on  the  plasma  screen  may  be  done 
without  subscripting  a  format  variable,  (which  is  syntactically 
illegal) , 

Common  Blocks  Used:  ZUNIT 
Called  by:  FDISPL 
Calls: 

SAHPLE 

This  subroutine  is  used  to  sample  the  user  performance 
measurements  collected  by  the  device  handler. 

Common  Blocks  Used:  ZFLAGS 
Called  by:  (main) 

Calls;  AKGET,  TDIF 
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SCAN 

This  subroutine  drives  the  interpretation  and  execution  of 
commands  (except  for  those  pseudo-commands  handled  by  FLDUPD  and 
TPANEL)  . 

Common  Blocks  Used:  ZMEMBY 
Called  by:  (main) 

Calls:  CMNDEX,  CMNDIN,  ERROR,  USCAN 

SCREEN  (assembly) 

This  function  converts  a  touch  panel  coordinate  into  a 
corresponding  screen  coordinate- 
Called  by:  TLOOK 
Calls: 

SDISPL 

This  subroutine  drives  the  display  of  the  static  elements  of  a 
page  on  the  plasma  screen. 

Common  Bloccks  Used:  ZLOC 


Called  by:  PDISPL 

Calls:  BULK,  DISPLA,  PWRITE,  TIME 


SELECT 


This  function  drives  execution  of  the  select  command,  which 
selects  a  subset  of  the  current  working  set  to  be  the  new  working 
set,  based  on  (complex)  relational  expressions  entered  by  the 
user.  The  system  is  left  in  the  no-record-yet-accesse J  condition. 
Called  by:  CMNDX1 

Calls:  BOOLN,  BSCAN,  GETREC,  MESSAG,  RECTST,  REMOVE 

SELERR 

This  subroutine  initiates  the  writing  of  error  messages  for 
errors  detected  during  syntax  analysis  of  the  select  command. 
Common  Blocks  Used:  ZUNIT 
Called  by:  ERROR 
Calls:  SELERl,  SELER2 

SELERI 

This  subroutine  writes  part  of  the  set  of  error  messages  for 
errors  detected  during  syntax  analysis  of  the  select  command. 
Common  Blocks  Used;  ZUNIT 
Called  by:  SELERR 


Calls: 
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SELER2 

This  subroutine  writes  part  of  the  set  of  error  messages  for 
errors  detected  during  syntax  analysis  of  the  select  command. 
Common  Blocks  Used:  ZUNIT 
Called  by:  SELEHR 
Calls: 


SLOOK 

This  function  translates  an  input  field  name  into  a  pointer  to 
the  descriptor  of  the  field  referenced. 

Called  by:  FLDNAM 


Calls:  LOOKUP 


STATIC 


This  subroutine  performs  LRU  buffered  I/O  of  file  status 
records. 


Common  Blocks  Used:  ZUNIT 


Called  by:  STATUS 

Calls:  BUFGET,  BUFPUT,  BUFHRT 


STATUS 

This  subroutine  swaps  the  status  records  to  allow  processing  of 
the  status  information  for  any  given  data  record. 

Called  by:  ADD,  GETBIT,  GETPTR,  LOGOFF,  PUTBIT,  PUTPTR 
Calls:  STATIC 
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SYMBOL 

This  function  assigns  relational  expressions  to  the  table  which 
is  used  during  the  evaluation  phase  of  the  select  command. 

Called  by;  BSCAN 
Calls:  MATCH 

TDIF  (assembly) 

This  function  computes  the  unsigned  difference  (modulo  65536) 
between  two  low  order  system  clock  60  hertz  tick  counts. 

Called  by:  ENDTIM,  SAMPLE 
Calls:  - 

TEXT 

This  function  extracts  the  next  symbol  from  a  command  line,  and 
returns  the  first  two  characters  of  that  symbol. 

Called  by:  CMNDIN 
Calls: 

TIME 

This  subroutine  synchronizes  use  of  the  user’s  UTIME  subroutine 
to  prevent  non- reentrancy  problems. 

Called  by:  FDISPL,  SDISPL 
calls;  PNHAIT,  UTIME 
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TIHGBT  (assenbly) 

This  function  returns  the  current  low  order  word  of  the  line 
frequency  clock. 

Called  by:  ENDTIH 
Calls: 

TLOOK 

This  function  translates  touch  coordinates  into  a  pointer  to 
the  descriptor  of  the  field  touched. 

Called  by:  TPANEL 
Calls:  SCBEEM 

TOKEN 

This  function  extracts  and  classifies  the  next  token  in  the 
relational  string  part  of  a  select  conaand  line. 

Called  by:  BSCAN 
Calls:  HATCH 

TOUCH  (assenbly) 

This  subroutine  activates/deactiwates  the  touch  panel. 

Called  by:  LOGOFF,  LOGON,  HBAPOP 
Calls: 
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TPJLNEL 

This  subroatlne  is  the  touch  panel  interrupt  conpletion 
routine. 

coanon  Blocks  Used:  ZFLAGS«  ZHEHBY,  ZTOOCH 
Called  by:  (aonitor) 

Calls:  HOVCUB,  PNHAIT,  TLOOK,  OTIHE,  UTOOCH 

VALUE 

This  function  extracts  the  next  syabol  froa  a  coaaand  line,  and 
tries  to  convert  it  to  an  integer  foraat. 

Called  by:  CHR0X1,  cnMDX2 
Calls:  CTT 

UBAPOP 

This  subroutine  is  invoked  during  prograa  teraination  to  allow 
device  deactivation. 

Coaaon  Blocks  Used:  ZFLA6S,  ZHEBBT,  ZUBIT 
Called  by:  (aaia) 

Calls:  CONOB,  LOGOFF,  PBKILL,  PBHAIT,  TOUCH,  OHBAP 


VIII.  FILE  CREATION/HAINTENANCE  UTILITY 


The  file  creation/maintenance  utility  for  the  Generic  Data 
Transaction  System  consists  of  two  parts.  The  first,  ULUPD, 
compacts  the  user's  disk  and  then  starts  the  second  part.  The 
second  part,  NPEOCU,  is  a  separate  program  that  lets  the  user 
perform  any  of  four  activities.  Each  of  these  activities  operates 
on  one  logical  file  at  a  time.  Each  logical  file  consists  of  a 
physical  data  file  and  a  physical  status  file  as  described  in  Part 
IV  of  this  document. 

The  four  activities  available  are:  1)  to  create  a  logical 
file;  2)  to  increase  the  capacity  of  a  logical  file;  3)  to  check  a 
logical  file  for  internal  consistency;  and  4)  to  reorder  the  data 
records  (in  a  logical  file)  so  that  their  logical  and  physical 
orders  are  the  same.  If  the  user  chooses  to  reorder  a  file 
(activity  four) ,  a  check  for  consistency  (activity  three)  is 
automatically  done  first. 

The  check  for  consistency  is  provided  because  an  abnormal 
termination  of  execution  of  the  generic  system  could  leave  changes 
to  the  logical  file  only  partially  recorded  in  the  permanent  disk 
files.  In  the  event  of  such  an  abnormal  termination,  a 
consistency  check  can  be  performed  to  determine  whether  or  not  the 
logical  file(s)  in  use  at  the  time  need  to  be  restored  from  back¬ 
up  copies.  A  consistency  check  is  automatically  done  before  a 
file  is  reordered  because  internal  consistency  is  necessary  for 
the  reordering  operation  to  function  correctly. 


The  I/O  operations  performed  by  the  generic  system  are  executed 
most  efficiently  when  the  logical  and  physical  orders  of  the  data 
records  are  identical.  If  many  data  records  have  been  added  to 
and  deleted  from  a  given  file  since  it  was  created,  the  records* 
logical  order  may  differ  significantly  from  their  physical  order. 
In  such  a  case,  a  reordering  of  the  data  records  (activity  four) 
could  significantly  improve  the  performance  of  the  generic  system. 
It  is  for  this  reason  that  the  reordering  option  was  included- 
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IX-  APPLICATION  SPECIFIC  PPOCEDURES 


Application  specific  procedures  may  exist  as  user  supplied 
software  appendages  at  strategic  points  in  the  generic  data 
transaction  system-  It  is  anticipated  that  the  procedures  will  be 
used  to  customize  the  operation  of  the  generic  system  in  such  a 
way  as  to  either  modify  or  extend  the  capabilities  required  by  the 
user’s  specific  application.  The  procedures  must  exist  as  FORTRAN 
IV  callable  subroutines  and/or  functions  in  order  to  be  compatible 
with  the  generic  system-  Also,  care  must  be  taken  in  the  design 
of  the  procedures  so  that  1)  the  return  path  through  the  overlay 
structure  is  preserved,  2)  procedures  called  by  completion 
routines  adhere  to  the  restrictions  for  that  type  of  subprogram, 
3)  procedures  called  as  synchronous  extensions  to  interrupt 
handlers  do  not  cause  the  issuance  of  EMTs  (emulator  traps 
intructions)  in  addition  to  the  above  restrictions  for  completion 
routines,  and  4)  as  an  added  restriction  for  completion  routines 
or  synchronous  extension  routines  there  may  not  be  any  overlay 
operations  invoked,  ie.,  all  subprograms  called  must  exist  in  the 
permanently  resident  program  segment. 


UCHECK 

This  function  is  called  by  FLDUPD  when  DTAELE(6,n)  contains  a 
non-zero  value  for  the  field  being  updated.  The  call  is  made 
immediately  prior  to  the  call  to  CVTPLD,  which  is  normally  used  to 
convert  and  assign  a  value  to  the  field  being  updated.  A  returned 
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value  of  zero  indicates  processing  is  coipplete  except  for  the 
reporting  of  any  detected  errors  (i. e.  the  field  has  been  updated, 
refreshed  on  the  screen,  and  FIELD  has  been  reset  if  no  field  is 
to  be  addressed  on  the  next  pass  through  the  control  cycle)  and  a 
returned  value  of  one  indicates  that  CVTFLD  wil\  be  called  after 
reporting  any  detected  errors. 

UERROR 

This  subroutine  is  called  by  ERROR  immediately  after  defining 
the  diagnostic  output  line  but  before  interpretation  of  the  error 
code.  Further  interpretation  of  the  error  code  into  the  normal 
set  of  messages  is  inhibited  by  setting  the  error  code  to  zero. 
The  error  count  in  the  user-performance  data  area  will  not  be 
incremented  except  when  recognizable  error  codes  are  interpreted 
into  the  normal  set  of  messages. 


OINITL 

This  subroutine  is  called  by  INITL  after  the  initial  screen 
erase,  the  assignment  of  the  standard  logical  units  and  completion 
routines,  and  initialization  of  the  user-performance  data  area. 

ULOG 

This  subroutine  is  called  by  LOGON  or  LOGOFF  (as  indicated  by  a 
flag)  immediately  before  resetting  the  user- performance  data  area. 
In  both  cases  the  screen  has  been  erased,  the  system  is  in  the  no- 
record-yet-accessed  condition,  and  the  control  record  is  current. 
When  the  calling  subroutine  is  LOGON,  the  touch  panel  is  active. 
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The  touch  panel  has  already  been  deactivated  when  the  calling 
subroutine  is  LOGOFF. 

UHSG 

This  subroutine  is  called  by  HESSAG  immediately  after  defining 
the  diagnostic  output  line  but  before  interpretation  of  the 
message  code.  Further  interpretaion  of  the  message  code  into  the 
normal  text  is  inhibited  by  setting  the  message  code  to  zero.  A 
message  code  of  minus  one  will  immediately  erase  the  diagnostic 
output  line. 

UPBNPT 

This  subroutine  is  called  by  (main)  at  the  beginning  of  each 
control  cycle  after  the  echo  line  is  defined  but  before  the 
command  read  is  initiated-  The  user- performance  data  area  has 
been  updated  to  reflect  the  most  current  command  before  the  call 
is  made. 

OSCAN 

This  function  is  called  by  SCAN  immediately  prior  to  the  normal 
interpretation  of  the  current  command  line  by  CHNDIN.  A  returned 
value  of  zero  indicates  that  processing  is  complete  except  for  the 
reporting  of  any  detected  errors,  and  a  returned  value  of  one 
indicates  that  CHNDIN  should  be  called  after  reporting  any 
detected  errors.  Only  commands  which  are  processed  by  CHNDIN  will 
result  in  the  updating  of  the  user-'performance  data  area. 
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UTEST 

This  function  is  called  by  PECTST  in  the  evaluation  of  a 
Boolean  "Select"  request  prior  to  the  normal  evaluation  of  an 
element  of  the  relational  expression  table  by  COMPAR.  A  binary 
zero  (false)  or  one  (true)  may  be  returned,  or  a  minus  one  may  be 
used  to  flaq  that  normal  evaluation  by  COMPAS  is  requested. 

UTIME 

This  subroutine  is  called  by  subroutine  TIME  for  both  of  the 
subroutines  FDISPL  and  SDISPL,  by  FORTRAN  IV  completion  routine 
TPANEL,  or  as  a  synchronous  extension  to  the  plasma  panel 
interrupt  server  precedinq  each  character  generation.  All  calls 
are  made  immediately  prior  to  an  operation  which  will  result  in 
alphanumeric  text  being  written  to  the  plasma  panel.  If  module 
NPBDCC  is  compiled  with  the  /D  switch,  (i. e.  UTIME  is  used  as  a 
synchronous  extension  to  the  plasma  panel  interrupt  hardware) , 
care  must  be  taken  that  UTIME  does  not  cause  an  EHT  to  be  issued. 
Otherwise,  the  usual  restrictions  normally  applying  to  completion 
routines  must  be  observed  unless  the  touch  panel  is  disabled  by 
OLOG.  A  flag  passed  to  UTIME  is  used  to  indicate  from  where  it 
was  called. 

UTOUCH 

This  subroutine  is  called  from  FORTRAN  IV  completion  routine 
TPAREL  before  any  other  processing  occurs  in  response  to  a  touch 
panel  interrupt.  The  restrictions  applying  to  completion  routines 


must  be  observed 
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UHRAP 

This  subroutine  is  called  from  WBAPUP  during  program 
termination  after  interrupts  to  the  plasma  panel  and  touch  panel 
have  been  disabled. 
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APPENDIX  A 
STATE  TABLES 


This  appendix  contains  a  tabular  description  of  the  finite 
state  automaton  used  in  the  parsing  of  arbitrarily  complex  boolean 
search  specifications  by  FORTAN  IV  subprogram  BSCAN  and  the 
operator  precedence  push-down  automaton  used  in  the  evaluation  of 
the  parsed  expressions  by  assembly  subprogram  BOOLN. 

The  entries  in  both  tables  are  constructed  similarly,  having 
the  form: 

A 

S 

B 

where  "A"  represents  the  action  or  action  (s)  to  be  taken;  ”S”  is 
the  next  state  (if  different  than  the  current  state) ;  and  "R"  is  a 
control  variable  value  (for  BSCAN)  or  statement  label  (for  BOOLN) 
indicating  which  section  of  each  subprogram  is  actually  executed. 


rt  H  >  h9  M 


TABLE  1:  State  Table  for  ESCAN 


CUFRENT  TOKEN 


1  2  3  4  5  6 

(  S  I  -•  )  string 
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7  10 
8  11 
9  12 
>=></< 


C 

U 

H 

B 

£ 

N 

T 


r  n 


1 

initial  1 

1 

-32  1 

1 

1 

2 

1 

1 

-8  1 
1 

4  1 
3  i 

1 

-6  1 

1 

3  1 

2  1 

-7 

1 

1 

1 

1 

I 

1 

1 

1 

2 

(  1 

-n  I 

2 

-9  1 

9  i 

-10  1 

5  1 

-12 

1 

1 

1 

1 

3  1 

1 

9  J 

1 

7  T  1 

7  ( 

7  D  T| 

1 

3 

string  i 

1 

-4 

8  1 

-14  1 

9  1 

-14  1 

-13 

1 

9  1 

5  1 

8  1 

1 

1 

I 

1 

( 

1 

4 

-17  1 

2 

-15  1 

9  1 

-16  1 

3  1 

-13 

i 

i 

1 

1 

3  1 

1 

2  1 

1 

1 

7  1 

7  D  1 

V 

1 

5 

(string  | 

-20  ( 

-4 

8  I 

-14  1 

9  1 

-3  J 

6 

1 

8  i 

5  J 

3  I 

11 

1 

1 

1 

1 

c  1 

1 

6 

>=><^<  1 

-23  1 

-5 

-22  1 

-24  1 

-21  1 

7  1 

-2 

1 

1 

1 

1 

12  1 

1 

1 

1 

0  ( 

1 

7 

value  1 

-33  1 

-19 

-25  1 

-34  1 

9  1 

-26  1 

-27 

1 

1 

1 

7  1 

! 

1 

I 

1 

1 

( 

8 

&1  1 

-31  1 

2 

-29  1 

9  1 

-30  1 

3  1 

-28 

1 

1 

1 

1 

3  1 

1 

2  1 

1 

T  1 

D  T  1 

1 

9 

)  1 

< 

-35 

8  1 

-38  1 

9  1 

-37  1 

-36 

1 

10  1 

6  I 

7  1 

\ 

\ 


i 


i 

i 


Actions:  I  =>  increment  parenthesis  counter 
D  =>  decrement  parenthesis  counter 
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T  =>  if  parenthesis  counter  not  balanced,  error  <-  - 1 
V  =>  relational  operator  code  <-  current  token  value  -  6 
7  =>  relational  operator  code  <-  7 
C  =>  close  relational  expression 

States;  #  =>  ISTAT  <-  # 


References;  #  =>  DEST  <-  t 


TABLE  2:  State  Table  for  BOOLN 
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C 

U 

P 

R 

E 

N 

T 


S 

T 

A 

T 

E 


u  T 

r  o 

r  r  k 

i  e  e 

o  n  n 

u  t 

s  T 

T  y 

1  T  op 

m  o 

b  k  e 

e  e 

r  n 


initial 
0  or 
{ 


1  operand 


3  Coperand 


5  I  operand 


CURRENT 


TOKEN 


e 

-1 

-2 

-3 

-4 

-5 

0 

>0 

n 

( 

e 
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operand 

1 

A 

1 

1 

A 

1 

1 

E 

1 

2 

1 

1 

1 

1 

I 

1 

1 

1 

2 

1 

1 

1 

1 

1 

1 

1 

1 

A 

1 

A 

D 

1 

B 

J 

1 

1 

- 

1 

2 

1 

4 

- 

1 

1 

1 

- 

1 

J 

1 

3 

1 

4 

5 

1 

6 

1 

1 

1 

A 

1 

1 

A 

1 

1 

E 

1 

1 

0 

1 

- 

1 

- 

- 

1 

- 

1 

3 

1 

1 

1 

1 

2 

1 

1 

8 

1 

1 

1 

A 

i 

c 

D 

1 

B 

1 

1 

1 

- 

1 

2 

1 

- 

1 

1 

1 

- 

1 

1 

1 

3 

I 

^0 

5 

1 

6 

» 

1 

I 

A 

J 

1 

A 

1 

1 

E 

1 

1 

0 

1 

- 

J 

- 

- 

1 

- 

1 

5 

1 

1 

1 

1 

1 

2 

1 

1 

9 

1 

1 

1 

A 

1 

C 

D 

1 

B 

1 

1 

1 

- 

J 

2 

1 

U 

- 

1 

1 

1 

- 

1 

1 

1 

3 

1 

10 

5 

1 

6 

( 

1 
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» 

Actions;  A  =>  push  operator 

B  =>  evaluate  stack  to  top;  return  result; 

error  if  parentheses  unbalanced 
C  =>  evaluate  stack  to  top  or  (;  push  result 
D  =>  evaluate  stack  to  (;  push  result; 

error  if  parentheses  unbalanced 
E  =>  evaluate  unary  operators;  push  result 

States:  # 

References;  1  =>  RECURS 

2  =>  PUSH 

3  =>  PUSH2 

4  =>  PUSH4 

5  =>  EVALR 

6  =>  EVALS 

7  =>  PEVAL1 

8  =>  PEVAL3 

9  =>  PEVAL5 

10  =>  EPUSH4 


